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fZ> (57) Abstract: A client device, such as a terminal (IE) in a telecommunication network, includes, in an IP packet it transmits, 
information (ID1 , ID2) on features of the client device requesting a service. The information can indicate e.g. which kind of operating 

^ system or application programming interface (API) the client device uses. This information is transmitted in the IP packet to a server 
(SI, S2, S3) to be utilized for selecting or cemfiguring a suitable application such that the service is provided in the form required 

O by the features and/or application of the particular client device that requested the service. Similar information can also be added to 

^ the IP packets or broadcast frames transmitted from the server to be used by the client device. The identifier information can also be 

^ used for routing the IP packet in the network. 
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PROVIDING SERVICESWrTH SERVER IN TCP/IP NETWORK 

[0001] The invention relates to providing services from a server in a 
TCP/IP network to different subscriber terminals. 

[0002] The Internet is simply the network of networks, which sup- 
5 ports TCP/IP (Transport Control Protocol/Internet Protocol) based applications, 
such as a World Wide Web (WWW), Simple Message Transport Protocol 
(SMTP) e-mail or File Transfer Protocol (FTP). The parts of the Internet are 
usually called subnetworks that have been interconnected by gateways or 
routers. Computers connected to the network are called hosts. One host is 
10 usually a client while another one is a server. A computer requesting or re- 
ceiving services from a computer in another network is called a client. A server 
is a computer which provides services to other computers in the network. Fig- 
ure 1 illustrates a TCP/IP protocol structure (according to an OSI model) and 
subnetworks, a router and host computers. 
1 5 [0003] In the bottom of a protocol stack there is provided a physical 

layer, which refers to the actual transfer medium over which data is transferred 
as electrical impulses or other such suitable signals. A host computer is con- 
nected to the transfer medium by a network adapter. A data link layer com- 
prises an interface to the network adapter and maintains a logical link to a 
20 subnetwork. Every network adapter has a unique and permanent physical ad- 
dress. In the lowest level, equipment-dependent protocols deliver data within 
the physical network, using the physical addresses of the adapters. Examples 
of network architectures of the physical data link layer include Ethernet, Asyn- 
chronous Transfer Mode (ATM) and Frame Relay. 
25 [0004] A network layer, or an Internet layer, is a layer in which the 

IP protocol provides logical, equipment-independent address processing so as 
to enable data to be transmitted from one subnetwork to another even if differ- 
ent technologies were used in the lower layers of the subnetworks. The IP 
protocol is a packet-switched protocol which is mainly responsible for routing 
30 IP packets over the Internet to their final destination and for informing the des- 
tination of the source. Therefore, a header of an IP packet comprises an IP 
source address and an IP destination address to unambiguously identify the 
original source and the final destination. The source and destination ad- 
dresses remain unchanged while the IP packet travels from the source to the 
35 destination. The TCP/IP networks use 32-bit addresses to identify the host 
computer and the network to which the host is connected. In other words, the 
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IP address comprises the address of the network and the address of the host. 
The TCP/IP uses protocols called Address Resolution Protocol (ARP) and Re- 
verse Address Resolution Protocol (RARP) to link these logical IP addresses 
to the actual physical addresses of the network adapters. An IP packet 
5 (datagram) also comprises the address (number) of the protocol (TCP, UDP, 
ICMP) of the transport layer to which the receiving computer is to forward a 
payload. 

[0005] A transport layer lies between a network and application 
layer applications. The most important protocols of the transport layer include 

10 a Transport Control Protocol (TCP) and User Datagram Protocol (UDP), which 
^ enable a particular application to be set as the destination of the data in the IP 

- ; packets. To be more precise, applications are connected to TCP and UDP 

protocol modules through "ports", each port being provided with a unique 
number, as illustrated in Figure 2. The ports are fixedly allocated to certain 

15 popular client/server applications at the server end, the allocation being stan- 
dardized to cover the entire Internet. Such ports are called well-known ports, 
and they enable a service application being compelled to advertise its port 
number before communicating to be avoided. When a client transmits an IP 
packet, it simply inserts the known port number of the destination application 

20 (server) into the destination port field of the UDP or TCP header and the free, 
unknown port number of the client into the source port field. When the server 
receives the first packet, the server is thus informed of the port number asso- 
O ciated with the client application. The different traffic streams of the end appli- 

cations communicating with each other can thus be distinguished from each 

25 other using a combination of five different identifiers; IP source address, 
2) source port, IP destination address, destination port and transport layer proto- 

col (TCP, UDP). When examining two packets, if one or more of these identifi- 
ers are different, the packets belong to different traffic streams. Examples of 
known TCP ports for the most common applications include port 21 for FTP 

30 applications, port 80 for WWW services (Hypertext Markup Language HTML), 
port 23 for Telenet services and port 25 for the SMTP e-mail protocol. Known 
UDP ports include port 42 for a name service and port 69 for a TFTP (Trivial 
FTP) service. In connection with ports, also sockets are usually mentioned. A 
socket is an address which is formed by combining an IP address and a port 

35 number. For example, socket 111.121.131.141.80 refers to port 80 of a com- 
puter whose IP address is 111.121.131.141. A socket address is thus an un- 
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ambiguous identifier of an application operating on a server. 

[0006] It is to be noted that a host computer may also be a remote 
workstation connected through a modem connection or the like to a dial-up 
server connected to the TCP/IP network. Dial-up protocols, such as a Serial 

5 Line Internet Protocol (SLIP) and Point-to-Point Protocol (PPP), are then gen- 
erally used in the network layer between the remote workstation and the dial- 
up server. As far as the IP layer and the higher layers are concerned, this, 
however, is a very similar situation to that in Figure 1, when the dial-up server 
is considered as operating as a router and a subnetwork 1 is the modem con- 

10 nection. 

[0007] An application layer comprises applications for detecting 
failures, transferring files, remote controlling a network and for Internet func- 
tions. The application layer also comprises application programming interfaces 
(API), which enable application programs operating above a certain operating 

15 system to use the network. However, the applications and different operating 
systems and/or APIs required from the applications by different client devices 
and terminals cause problems particularly to the service providers. In the fol- 
lowing, new multimedia applications will be examined by way of example. 

[0008] New digital broadcast networks have been developed all 

20 over the world for delivering radio and television broadcasts. Such networks 
include e.g. a digital radio network called Digital Audio Broadcasting (DAB) 
and a digital television network called Digital Video Broadcasting (DVB). DAB j 
and DVB systems also comprise bidirectional, interactive services that enable 
e.g. chargeable services to be subscribed to or feedback information on a 

25 service to be transmitted from a terminal in a network. Such interactive serv- 
ices include e.g. electric commerce, different games and video-on-demand 

i 

services. This requires that the terminal also comprises means for transmitting 
data on a return connection, i.e. transmitting data to a broadcast network. 
Typically, a terminal is then provided with a wired connection to a fixed net- 

30 work, such as a Public Switched Telephone Network (PSTN), from which a 
further connection is arranged to a DAB or DVB network. The return connec- 
tion can also be arranged using a cable or a wireless connection, such as a 
wireless local area network or a mobile communication network. The return 
connection enables different information, which can be any data, to be se- 

35 lected to be broadcast. Typically, the image or voice information to be broad- 
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cast is obtained from the servers of the network of the service provider, such 
as a television broadcast company. 

[0009] As the wireless data transfer technologies advance, more 
and more services are shifted to be carried out through different wireiess teie- 
5 communication networks. Technical limitations of the wireless data transfer 
explain why different networks have typically been developed for different 
services. For example, it is reasonable to implement broadband wireless data 
transfer directed, to one terminal technically as a short-range network only. In 
order to utilize the services of each network, network-specific applications 

10 have typically been developed that can typically only be used by terminals 
separately designed for the network. Furthermore, each network is typically 
provided with unique interfaces between terminals and different network ele- 
ments. The recent trend in order to converge different wired and wireless 
services has introduced new solutions for integrating different terminals. For / 

15 instance, an extension card connected to a personal computer (PC) enables 
digital broadcast services, such as DAB or DVB, to be received. Solutions are 
also known wherein a computer and an interface card to a Wireless Local 
Area Network (WLAN) are connected to a single terminal. Solutions for con- 
necting a local area network card have also been provided for a mobile station 

20 in a cellular radio network, such as a GSM network. The terminal to receive 
broadcasts can be e.g. a "Set-Top Box" (STB). The STB device enables digital j 

broadcasts or Internet services to be received by the existing analogue TV and / 

i 

radio receivers. The received broadcast is demodulated, decoded and demul- / 
tiplexed at the terminal. The typically source encoded signal thus obtained can j 

25 be further deconstructed into actual information e.g. by decoding the MPEG-2 ( 
coding. i 

[0010] The convergence of different telecommunication networks 
and services and integration of terminals enable services conventionally pro- 
vided by a certain network to be received through another network. For exam- 

30 pie, a computer is able to receive digital radio and TV broadcasts through an 
Internet connection by means of the access cards mentioned above. Similarly, 
connecting a broadband wireless local area network card to a mobile station 
enables video image to be received through a conventional mobile station. A 
tendency that can be clearly discerned in this process is to provide, in the fu- 

35 ture, services provided by different networks through the Internet, either with 
or without wires. 
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[0011] In digital data transfer, audio and video constitute packet 
streams interleaved into each other in terms of time by multiplexing. In the 
digital video broadcasting (DVB), these packet streams are called elementary 
streams. Some of the DVB packets may contain time stamps, which are used 

5 for constructing the original real time image by image, i.e. the relationship be- 
tween presentation and time. For example, a mere audio signal necessitates a 
"presentation time stamp" while synchronized image and voice require "lip 
sync" synchronized with the same master clock. In the DVB transmission, 
elementary stream packets are placed in a broadcast transmission channel, 

10 i.e. a satellite or a terrestrial distribution channel. Prior to coding according to 
the transmission channel, the elementary stream packets are "normal" packets 
having a fixed number of bits, which can be transmitted through any transmis- 
sion network. The network is only required to be able to provide enough 
transmission capacity for reconstructing the real-time time axis at a receiver. 

15 [0012] An MPEG4 standard is a system for arranging multimedia 

presentations containing moving image and voice. The standard is sufficiently 
provided with information so as to initialize a terminal for a multimedia event 
and also with specifications for initializing the memory and transmission path 
interface necessary for the event. In the elementary streams, a multimedia 

20 presentation is separated into parts, each elementary stream containing a dif- 
ferent aspect of information. Information types include object description, im- 
age and voice data of one object, stage description and information on the 
contents of an object. An MHEG2 (Multimedia Hypermedia Expert Group) has 
specified a simpler hypermedia language, which is also optionally able to util- 

25 ize an MPEG2 hardware decoder. An SMIL (Synchronized Multimedia Inte- 
gration Language) is an international WWW consortium recommendation for 
constructing a multimedia presentation. It can be an alternative to the MHEG 
in HTML based programming interfaces (API). It can be said that the MPEG2 
is a multimedia storage format like MID, WAV, MP3 or AVI and MPEG4 are. 

30 The presentation an MPEG file requires a presentation program. The presen- 
tation program for an Internet Explorer browser is Microsoft Media Player. 
This, however, requires the entire file to be downloaded into the memory of the 
terminal before the program is able to deconstruct it into a multimedia pres- 
entation. 

35 [0013] However, the streaming formats mentioned above enable 

multimedia to be presented according as a client device receives data. For 
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example, Stream Works software by Xing Technologies Inc. is based on the 
MPEG4, also supporting an IP multicast service. As the transmission capacity 
of information networks increases, the transmission capacity required by 
MPEG2 video and audio will no longer be problematic either. 
5 [0014] As far as the terminals (generally client devices) are con- 

cerned, the problem with the multimedia presentation formats described above 
is the high processing capacity they require. A terminal in a fixed broadband 
network is able to process decoded multimedia presentations by software. In 
small and portable, usually wireless terminals, on the other hand, the limited 
10 capacity presents a problem. A small display, for example, is already a special 
_ limitation. Similarly, the display sets limitations in Internet solutions wherein a 

J conventional television receiver operates as the display. 

[0015] As the mobile telecommunication and DVB services develop, 
new multimedia services will be introduced that operate e.g. on top of a Java 
15 machine or an MPEG machine (API), whereas in personal computers (PC) the 
most common operating system is Windows. New operating systems for mo- 
bile stations include EPOC and Windows CE. A WWW-type WAP (Wireless 
Application Protocol) protocol and a WML (Wireless Markup Language) have 
also been provided for wireless devices. The features of the terminals do vary 
20 e.g. in mobile communication networks and in a wired telecommunication net- 
work, and it is thus natural to develop unique operating systems and pro- 
gramming interfaces (API) that are best suited each for their own environment. 
O The operating systems and application interfaces (API) for mobile devices op- 

timize application access to the resources of a device. In client devices, the 
25 API of the device operates as a software interface to the telecommunication 
arid other resources of the device. As far as the applications are concerned, 
these are similar programming interfaces (API) e.g. to those in Java and 
MHEG digital television receivers, whose run time version operates in the cli- 
ent device when services are being used. The IP packets provide information 
30 on the application to be used according to the TCP port number. HTTP or FTP 
applications, for example, have their own port numbers, the applications them- 
selves being responsible for supporting multimedia presentations. Same appli- 
cations and multimedia presentation methods are, however, used in different 
operation system and software interface environments. The features of the 
35 terminals differ so much from each other that, in order to be able to utilize 
services, the file storage format to be selected and transmitted in response to 



o 



WO 01/78350 



PCT/FI01/00343 



7 

service requests has to conform with the software environment of the client 
device. As far as the service provider is concerned, however, the situation is 
more problematic. The aim is to provide the users of different telecommunica- 
tion networks with same content services, most preferably even from the same 

5 server and a single Internet address. In principle, this is feasible since the ter- 
minals in more and more networks have Internet capability, being capable of 
communicating with a server connected to the Internet. It is simple, as such, 
e.g. to transfer a multimedia presentation from a server to a terminal according 
to the TCP/IP routing principles described above. The problem is, however, 

10 the way in which a multimedia presentation can be transmitted to mobile ter- 
minals or fixed terminals equipped with multimedia encoders implemented by 
different software or hardware such that the transmitted multimedia presenta- 
tion is presented by an appropriate standard enabling a particular terminal to 
process the presentation. The current solutions do not by any means enable 

15 the server to find out the application layer standard or technology used by the 
terminal and to conform its transmission therewith. The only way is to use dif- 
ferent IP addresses or servers for different kind of terminals, to which the ter- 
minals themselves must be able to transmit a service request. It could also be 
possible to identify packets supplied from different networks and to route them 

20 to the correct servers or applications by analysing the network identifiers of the 
source addresses of the IP packets. 

[0016] An object of the invention is to enable a service to be trans- 
mitted from a server to a client device in the form selected according to the 
features of the client device. 

25 [0017] This is achieved by a method for implementing a service 

from a server to client devices having different features, the method compris- 
ing the steps of a client device transmitting an Internet Protocol (IP) packet 
comprising an IP header, a transfer protocol layer header and application layer 
data; routing the IP packet to the server according to a destination address of 

30 said IP header, transferring, at the server, the transport layer header and the 
application layer data from the IP layer to the transport layer protocol accord- 
ing to a protocol identifier of said IP header; transferring, at the server, the ap- 
plication layer data from the transfer protocol layer to the application layer ac- 
cording to a port number contained in said transfer protocol layer header. The 

35 method is characterized in that the client device (TE) includes, in the IP packet 
it transmits, information on a software interface (API) used by the applications 



WO 01/78350 



PCT/FI01/00343 



of the client device requesting a sen/ice, and said information is used at the 
server for selecting and/or configuring either a file requested by the client de- 
vice or an application interacting with the client device such that the service is 
provided in the form required by the features of the particular client device 
5 which requested the service. 

[0018] This object is also achieved by a terminal and a server ac- 
cording to claims 8 and 9. 

[0019] The idea underlying the invention is that a client device, 
such as a terminal in a telecommunication network, includes, in an IP packet it 

10 transmits, information on the features of the client device requesting a service. 
This information may reveal e.g. what kind of operating system or application 
programming interface (API) the client device uses. In a preferred embodiment 
of the invention, the information is an identifier whose certain values are ar- 
ranged to refer to a certain feature or a combination of features of the client 

15 device or the application. This information is forwarded in the IP packet to the 
server to be utilized in selecting a suitable application for configuration such 
that the service is provided in the form required by the features and/or applica- 
tion of the particular client device requesting the service. Thanks to the inven- 
tion, as far as a service provider is concerned, different networks are inte- 

20 grated into a single whole such that when the operator connects a server to a 
network, the server, based on the IP, is able to serve requests supplied 
through the same fixed Internet connection since the payload of the services 
can be transmitted in a standard form understood by a particular terminal. 
There is no need for the service provider to set up any extra network service 

25 interfaces in order to reach the clients which access the IP world through dif- 
ferent networks. 

[0020] When the identifier information according to the invention is 
used in the IP packet in addition to the known port numbers and protocol 
numbers, the server is also able to serve "conventional" clients, which do not 

30 support the functionality of the invention. If the IP packet received by the 
server contains no identifier information, the server provides the service typi- 
cally referred to by the known port number or protocol number of the IP 
packet. If the packet does contain the identifier information, the client will re- 
ceive a service customized according to its wishes. The terminal, in turn, may 

35 always add the identifier information to the IP packet and be ensured that it 
will, however, receive the service at least in the form according to the "known" 
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port number if the server should not support the special format desired by the 
terminal. In other words, some kind of service will always be ensured. 

[0021] The information or identifier according to the invention can, 
in principle, be included in any part of the IP packet. It may be included e.g. in 
5 the IP header, transport layer header or in the application layer data itself. The 
IP header or the transport layer header may employ suitable undetermined bit 
positions or fields, or parameters already being used may be given new val- 
ues. 

[0022] In an embodiment of the invention, when the identifier infor- 

10 mation on the software interface below the application is included in the appli- 
cation data, the application layer itself can be configured to support providing 
the service and selecting the file to be transmitted to the client in a form suit- 
able for the client device that transmitted the service request. In an embodi- 
ment of the invention, SLP (Service Location Protocol) or the like is used for 

15 making a server providing a suitable service easier to find for the terminal. 
Available services, different formats thereof and port numbers, protocol num- 
bers and/or identifiers to be used for requesting different services and different 
service formats are stored in connection with a directory agent. When a user 
of the terminal is to establish a connection to a particular service, it issues, 

20 directly or indirectly, a service request to the directory agent. The user of the 
terminal does not need to know any detailed information on said service, such 
as at which network address the service is available or the telecommunication 
parameters used. In the service request issued, the user of the terminal can 
specify different attributes of the desired service, such as the service type, 

25 network protocols and service formats supported by the terminal, and certain 
information concerning the features of the software interface of the terminal 
that affects the selection of the service format. The directory agent searches 
through the services registered therein for the service description specified by 
the service request. If a service according to the service request is available, 

30 the directory agent returns the service information, such as the URL address, 
on the servers providing the particular service. This method for finding a server 
is particularly suitable when a terminal should know a certain port number or a 
protocol number in order to receive a service in a correct form from the server. 

[0023] Another object of the invention is to enable a multicast and 

35 broadcast service to be transmitted in a form on the basis of which a client de- 
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vice is able to download a correct application interface and application so as to 
present the service to the client in a correct form. 

[0024] This is achieved by a method according to claim 15, servers 
according to claims 17 and 18, and a terminal according to claims 19 and 20. 
5 [0025] Herein, the basic principle of the invention, i.e. an application 

programming interface identifier, is applied in an opposite direction, i.e. for 
controlling a client device from a server. When the server transmits its services 
in the broadcast or multicast form, the server includes, in the IP packet it 
transmits, information on the software interface below the application used for 

10 presenting the service, and that said information is used at a client device for 
configuring and/or downloading the application and application programming 
interface from the client device or the network. 

[0026] When transmission is carried out directly from a media 
server of a broadcast network, e.g. in a DVB or DAB multiplex, the software 

15 interface identifier can also be placed in the identifier information on a multi- 
plexed broadcast frame, in which case the client device (broadcast receiver) is 
able to'download a correct software interface and application or a protocol 
program from its memory or the network. 

[0027] While receiving the service, the client device can thus select 

20 a software environment according to the service for both the API and the ap- 
plication as well. For example, a request message supplied from a Wireless 
Application Protocol (WAP) network to an Internet WWW server through a 
WAP proxy or a gateway may be supplied from a mobile terminal having a 
standardized WAP protocol stack per se, but since mobile WAP terminals em- 

25 ploy different software interfaces and therefore also different applications, the 
request should preferably contain information indicating which software inter- 
face (e.g. EPOC or Windows CE) or even which software interface version the 
device uses. When this software interface is known, it is also possible to 
download necessary M plug-ins w f i.e. software modules suitable for the software 

30 interface of the client device, from servers on the Internet by utilizing the soft- 
ware interface identifier according to the invention so as to present the service 
content itself. 

[0028] Yet another aspect of the invention is a routing method ac- 
cording to claim 21 and a router according to claim 23. 
35 [0029] The identifier information according to the invention can also 

be used for routing an IP packet in a network. Depending on the identifier in- 



WO 01/78350 



PCT/FI01/00343 



formation, an IP packet having the same IP address can be routed in different 
ways in an embodiment of the invention: In the service provider's own local 
area network, two or more servers (possibly virtual) can be accessed using the 
same IP address. Routing to a correct server within a network is determined 
5 according to the identifier information of the invention. 

[0030] In the following, the invention will be explained by means of 
the preferred embodiments and with reference to the accompanying drawings, 
in which 

[0031] Figure 1 illustrates a TCP/IP protocol structure and subnet- 
1 0 works, a router and host computers, 

[0032] Figure 2 shows a protocol stack illustrating how a transport 
layer is divided into TCP and UDP protocol modules, and ports through which 
these are connected to application layer applications, . 

[0033] Figure 3 shows a telecommunication system whereto the in- 
1 5 vention can be applied, 

. [0034] Figure 4 is a protocol stack according to a preferred em- 
bodiment of the invention, 

[0035] Figure 5 is a protocol stack according to a preferred em- 
bodiment of the invention, wherein a port from the transport layer to the appli- 
20 cation layer is selected on the basis of an identifier according to the invention 
and a received port number, 

[0036] Figure 6 is a flow diagram illustrating a process according to 
the invention, which operates in the transport layer in the embodiment of Fig- 
ure 4, 

25 [0037] Figure 7 is a protocol stack according to another embodi- 

ment of the invention, wherein a network layer selects a protocol identifier and 
a transport layer protocol module on the basis of information according to the 
invention, and 

[0038] Figure 8 is a flow diagram of a process implementing the 
30 operation of a network layer of the invention in the embodiment of Figure 7. 

[0039] The present invention is suitable for use in all telecommuni- 
cation systems wherein a client device, typically a terminal in a telecommuni- 
cation network, is able to communicate through a TCP/IP protocol stack with a 
server connected to the same or another network. The server may be e.g. a 
35 server generally providing services on the Internet, and the client a terminal in 
a wired or wireless telecommunication network. 
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[0040] Figure 3 illustrates a telecommunication system comprising 
a network BN providing broadcasts to a terminal TE f and a network RN pro- 
viding a return connection to the terminal. Information is delivered to the termi- 
nal TE as a broadcast via the Internet from servers S1 and S2 or from servers 
5 S3 and S3 1 connected to a local area network Lan. 

[0041] The terminal TE receives broadcasts from the broadcast 
network BN. Typically, a broadcast comprises information presented by means 
of an electronic programming guide (EPG) on services and programs that can 
be selected by a user. The terminal TE preferably shows the information by 
10 means of a browser-type user interface wherein different information sources 
are linked (cf. hyperlinks in a WWW browser). The information can be divided 
J) into services which do not require a return connection to be set up and into 

services which do require a return connection to be set up. A return connec- 
tion must also be set up if the user desires to receive services elsewhere than 
15 from the network BN. 

[0042] When the user is to transfer information, such as a multime- 
dia presentation, from the server S1, S2 or S3 connected to the internet via a 
high-speed broadcast, the TE delivers a request for a return connection to be 
set up via the Internet to a particular server S1, S2 or S3 on the basis of an 
20 URL identifier (IP address) identifying the service. 

[0043] The return connection can be arranged wirelessly e.g. via a 
GSM (Global System for Mobile communications) network or a wireless local 
P) area network. On the other hand, the return connection can also be arranged 

via a wired network, such as a cable network, a PSTN (Public Switched Tele- 
25 phone Network) network or an ISDN (Integrated Sen/ices Digital Network) 
network. The terminal TE comprises the necessary functions both for setting 
up a return connection and for receiving broadcasts, preferably integrated in a 
single device. The identifier of the network BN is stored in the terminal TE, e.g. 
on a smart card. A BSP is e.g. a digital television network (digital TV). In the 
30 future in particular, when the transmission rate of also the wireless networks is 
high enough (third generation mobile communication systems), the return net- 
work and the broadcast network can be a single network, and transmission 
can take place in both directions through the same connection. 

[0044] If connection setup to the server S1 or S2 succeeds, infor- 
35 mation is delivered from the server to the IP address specified by the request. 
The information may comprise e.g. a file to be transmitted using a WWW page 
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or an FTP protocol. The information is delivered to the terminal TE as a broad- 
cast via the network BN. Preferably, the broadcast information is encrypted 
such that the encryption can be decrypted only by the terminal TE that se- 
lected the information through the return connection. This can be implemented 

5 e.g. by delivering the necessary keys for decrypting the encryption to the ter- 
minal TE. The keys necessary for decryption are preferably stored on a smart 
card, which makes it easy for the user to change his or her terminal. When 
information is broadcast to the terminal TE, the network BN encrypts the in- 
formation, using an encryption key matching the decryption key of the TE. 

10 [0045] A terminal TE to receive broadcasts can be e.g. a "set-top 

box" (STB). The STB device enables digital broadcasts or Internet services to 
be received by the existing analogue TV and radio receivers. The terminal TE 
may also be integrated into a computer e.g. by means of different PC receiver 
cams. Furthermore, the terminal can be a mobile station or it can be integrated 

15 into a mobile station. At the terminal TE, the received broadcast is demodu- 
lated, decoded and demultiplexed. The typically source encoded signal thus 
obtained can be further deconstructed into actual information e.g. by decoding 
the MPEG-2 coding. 

[0046] An environment has been described above that is remarka- 

20 bly well suited to the invention. The invention is not, however, restricted to 
these networks; below, the invention will be described generally, without being 
connected to particular networks. 

[0047] The basic principle of the invention is that a client device, 
e.g. host A in Figure 1 or the terminal TE in Figure 3, adds an Identifier pro- 

25 viding information on a software interface of the client device to an IP packet it 
transmits to a server (e.g. host B in Figure 1 or the server S1 in Figure 3), on 
the basis of which information the server knows in which form the data associ- 
ated with a service should be transmitted to the client device. In principle, it is 
irrelevant to the invention at which point of the IP packet or in which form the 

30 information is transmitted. In practice, however, a manner is selected which 
complicates or changes the usual operation of the TCP/IP protocols as little as 
possible. Usually it is preferable to select a field or a bit position that has not 
been used before. The new facility of the invention is then invisible to devices 
which do not support it. It is also feasible to provide fields already being used 

35 with new values, but this may cause problems with servers not knowing the 
new value and the meaning thereof. The position at which the information is 
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placed is sometimes also affected by the fact in which protocol layer the server 
utilizes the information. For example, it is not necessarily a good idea to place 
the information in the IP header if the information will not be used until in the 
TCP/UDP layer since the IP header will not be transmitted to the transport 
5 layer. The information must then be transmitted from a lower layer to a higher 
layer in some other way. In the preferred embodiments of the invention to be 
described below, some alternatives for placing the information in an IP packet 
will be suggested, but the invention is not to be restricted to these examples. 

[0048] In the client device, the protocol stack (host A or the terminal 

10 TE) is in accordance with Figure 1. Furthermore, a new process is needed in 
the part of the program which adds the identifier information according to the 
invention. For example, if the identifier information is added in a network layer 
IP, the new process must then be added to the IP program, which composes 
an IP packet. The program can be configured to attach a certain identifier to 

15 the packets of a particular application while the application is being installed. 
An identifier can be added based e.g. on a port number. When the TCP/UDP 
transport layer receives data from a particular application port, a predeter- 
mined identifier is added to a corresponding IP packet. 

[0049] Two versions of IP packets have currently been specified, 

20 version 4 (IPv4) and version 6 (IPv6). An IPv6 header can employ extension 
headers and particularly a destination options header. No exact use has yet 
been specified for this extension header, but it is meant to transfer information 
to be examined by a destination node (device). It is thus well suited to the pur- 
pose of the invention. An IPv4 header also comprises an options field of a 

25 varying length, which can be used for transmitting the identifier information of 
the invention. A TCP header comprises a 6-bit field reserved for later use; part 
of the field might possibly be used for the identifier information of the invention. 

[0050] In a preferred embodiment of the invention, an application 
software interface process is selected or downloaded on top of a protocol layer 

30 of the transport layer (TCP or UDP) using an application software interface 
identifier (API identifier). A TCP or UDP software module can adapt the IP 
software module and the application software interface to each other, i.e. the 
TCP/UDP protocol software is downloaded at the server according to the soft- 
ware interface. Alternatively, the software interface is provided for the 

35 TCP/UDP software module, in which case the TCP/UDP protocol software 
module remains the same, regardless of the application software interface. 
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[0051] The preferred embodiment of the invention is illustrated in 
Figure 4 showing a protocol structure at a server end. TCP and UDP protocol 
module interfaces to the applications are provided by ports, which are speci- 
fied by port numbers x and y. Lower protocol layers TCP, UDT, IP and a data 
5 link layer and a physical layer can then be completely standardized {cf. Figure 
2). An application software module comprising two different applications 1 and 
3 and two different software interfaces API1 and API2 to be selected or 
downloaded according to the API identifier of the invention is connected to 
TCP port Y. One application and one application programming interface API1 

10 can be selected or downloaded through TCP port X. Similarly, UDP port X 
comprises application 4 and application software interfaces API1 and API2 to 
be selected or downloaded. A selection process, illustrated by API MUX in the 
figure, carries out the selection on the basis of the received API identifier. If 
the terminal transmits the API identifier in an IP packet in the application layer 

15 data, e.g. in the header of a protocol data unit (a packet or a frame) according 
to the particular service, the API MUX receives the API identifier directly in the 
application data. If, again, the API identifier is received in the header fields of 
the IP or transport layer, a lower protocol module extracts the API identifier 
from the IP packet and forwards it to the API MUX module. Generally speak- 

20 ing, the application software and the related "API software", possibly even a 
TCP/UDP module, are selected, downloaded or configured according to a re- 
ceived API identifier. 

[0052] In the present application, the term "application program- 
ming interface API" should be understood broadly. It may contain an applica- 

25 tion programming interface (API), also an operating system on top of which the 
application has been implemented, and other facilities related to signal proc- 
essing, use of lower protocol layer services or a service format suitable for the 
client device. In the present example, it is assumed that the API1 is an inter- 
face suitable for a terminal in a fixed network and the API2 is an interface surt- 

30 able for a terminal in a wireless network. Another possible example is that the 
API1 is designated for terminals in a fixed broadband network that are able to 
process decoded multimedia presentations by software while the API2 is des- 
ignated for terminals that are capable of processing multimedia presentations 
decoded by hardware. The API versions may also differ in that they are capa- 

35 ble of supporting different multimedia objects and/or different stage descrip- 
tions. 
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[0053] When the API identifier information is in the application data 
(the data field of the IP packet), the application layer data of the received IP 
packet can be transmitted in a usual manner to a particular port to the applica- 
tion layer according to the received protocol number and port number. In Fig- 
5 ure 4, two databases DB1 and DB2 are connected to application 2, the appli- 
cation layer selecting a file to be transmitted according to the API identifier 
from one of the databases. The databases provide e.g. different multimedia 
objects or stage descriptions. The application examines whether the received 
data contains an identifier ID, and on the basis of the identifier it selects which 

10 type of file is to be transmitted to the client. For example, an identifier ID1 may 
cause a file to be transmitted from the database DB1 whereas an identifier ID2 
causes a file to be transmitted from the database DB2. If the user data con- 
tains no identifier ID, the default database DB1 is selected. 

[0054] Application 2 of Figure 4 may be e.g. an application provid- 

15 ing a WWW service (known TCP port 80). When the API layer or application 2 
receives the API identifier in the application data from port x (port 80), on the 
basis of the API identifier it selects from its file hierarchy a file corresponding to 
the application software interface of the client, and thus the application, to be 
transmitted to the client. This basic principle of the invention can also be ap- 

20 plied in the opposite direction by transmitting a multicast and broadcast serv- 
ice in a form on the basis of which the client device is able to download a cor- 
rect application interface and application so as to present a service in a correct 
form to the client. For example, when the server S1 transmits its sen/ice in the 
broadcast or multicast form, the server includes, in the IP packet it transmits, 

25 information on the software interface API1 or API2 below the application used 
for presenting the service. The client device TE receiving the IP packet uses 
this information for configuring and/or downloading the application and appli- 
cation programming interface or the protocol program module (such as the 
TCP or UDP) either from the program memory of the client device or the net- 

30 work. This can take place as was explained in connection with the server with 
reference to Figure 4. The solutions described below with reference to Figures 
5 to 8 can also be applied to the terminal. An example of a suitable application 
programming interface is a run time version for a Java machine, which is 
downloaded after the terminal has identified the software interface information 

35 from the received IP packet. An application supporting the Java machine, such 
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as an HTTP application, is downloaded on top of the Java machine according 
to the port number of the application. 

[0055] If the server is located in a broadcast network, as the BN in 
Figure 3, the server can include, in the identifier information on broadcast 
5 frames, information on the software interface below the application used for 
presenting the service. The client device TE uses this information for config- 
uring and/or downloading the application and application programming inter- 
face or the protocol program as described above. 

[0056] Figure 5 illustrates a protocol structure at a server end in an 

10 embodiment of the invention wherein the API identifier is transmitted in the IP 
header of the IP packet and the identifier information is used in the network 
layer in the IP protocol program module. The transport layer comprises two or 
more TCP protocol program modules TCP1 and TCP2 and two or more UDP 
protocol program modules UDP1 and UDP2. The TCP module TCP1 com- 

15 prises port Y, to which application 1 equipped with the application program- 
ming interface API1 is connected. Port Y of TCP program module 2 is con- 
nected to application V equipped with a different interface API2. Applications 1 
and 1' provide the same service, although in different formats, which is primar- 
ily determined by the functions illustrated on the interfaces API1 and API2. At 

20 their simplest, applications 1 and V can be similar except for the API inter- 
faces, but in practice the differences may be greater. Ports X of the TCP pro- 
gram modules 1 and 2 are connected through the different interfaces API1 and 
API2 to different versions 2 and 2' of the same application. The same service 
is thus provided through the ports, only suited for different client device types 

25 or client applications. Similarly, ports X of the UDP program modules 1 and 2 
are connected to different versions 3 and 3' of the same application through 
the different interfaces API1 and API2, in which case they provide the same 
service suited for different client devices or client applications. In the protocol 
architecture of Figure 5, the IP program module transmits the TCP header or 

30 the UDP header and the application layer data to the correct TCP or UDP pro- 
gram module on the basis of the identifier information ID of the invention and 
the protocol number in the IP header (TCP = 6, UDP = 17). This protocol num- 
ber is in the protocol field in the IPv4 header and in the next header field in the 
IPv6 header. The TCP and UDP units are selected e.g. as disclosed in the 

35 flow diagram of Figure 6. The IP program receives the IP packet in step 41 
and examines the IP header. In step 42, it is examined whether the protocol 
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number is the number determined for the TCP protocol. If so, the process 
moves on to step 43 to examine whether the identifier number of the invention 
is the same as the identifier number ID1 of the TCP program module 1. If so, 
the program module TCP1 is selected in step 44, and the TCP header and the 
5 application data are transmitted thereto. Next, the TCP program module TCP1 
transmits the application layer data to port Y or X, according to the port num- 
ber in the received TCP header. If the received identifier ID did not correspond 
to the identifier ID1 in step 43, it is examined in step 45 whether the received 
identifier corresponds to the identifier ID2 of another TCP program module 

10' TCP2. If so, the TCP2 is selected and the TCP header and the application 
layer data are transmitted thereto. If the received ID and ID2 do not match in 
step 45, the process moves on to check a next identifier IDn in step 47, and a 
corresponding program module TCPn is selected if the identifiers match. If the 
received ID does not match with any identifier ID used at the server, the re- 

15 ceived identifier is defined as unknown, and a default TCP program module is 
selected. This could typically be a TCP connected to an application supporting 
a terminal in a fixed broadband network, since it is more likely that a terminal 
using special features also knows how to use the identifier ID. If the received 
IP packet contains no identifier ID of the invention at all, a default TCP module 

20 will also be selected since the packet has then probably been supplied from a 
client device in a fixed network. 

[0057] If, in step 42, the protocol number does not correspond to 
the TCP protocol number, it is assumed that the protocol is UDP, and the 
process moves on to steps 50, 52 and 54 to check whether the received ID 

25 corresponds to any one of the identifiers ID1, ID2,...IDn, and a corresponding 
UDP program module UDP1 ...n is selected in steps 51, 53 and 55. If there is 
no received ID at all or it is unknown, a default UDP is again selected in step 
56. In the UDP program modules 1 and 2, the application layer data is also 
transmitted to a port indicated by the port number in the received UDP header. 

30 [0058] Figure 7 shows a second protocol architecture comprising 

only one TCP program module and one UDP program module, as usual. A 
new feature, however, is that the TCP program module comprises two ports 
designated by port number X and two ports designated by port number Y. 
Similarly, the UDP program module comprises two ports designated by re- 

35 ceived port number X. The TCP program module selects a correct port on the 
basis of both the received port number and the received identifier ID. If the 
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received identifier is ID1 and the received port number is X, the application 
layer data is directed to port X, which is connected to application 2 through the 
interface API1. If the received identifier is ID2 and the port number is X, the 
application layer data is directed to port X', which is connected to application 2' 
5 of a similar type through the different interface API2. Similarly, port Y is se- 
lected if port number Y and the identifier ID1 are received. Port Y' is selected if 
port number Y and the identifier ID2 are received. If there is no ID at all or it is 
unknown, the port is select on the basis of the received port number only. 
Method steps 61, 62 and 63 in the flow diagram of Figure 8 illustrate the op- 
10 eration of a TCP program module. The TCP program module can obtain the 
received identifier from the TCP header. Another alternative is that the IP pro- 
gram module has received the identifier ID in the IP header of a packet and 
transmits the identifier to the TCP program module as a parameter, as illus- 
trated by arrow 71 in Figure 6. 
15 [0059] The UDP program module operates in a similar manner. If 

port number X and the identifier ID1 are received, port X is selected, which is 
connected to application 4 through the interface API1. If port number X and 
the identifier ID2 are received, port X' is selected, which is connected to appli- 
cation 4 through the interface API2. Again, the UDP program module can re- 
20 ceive the identifier ID either from the UDP header or as a separate parameter 
72 from the IP layer. 

[0060] An advantage of the embodiments described above is that 
they enable generally known port numbers to be used for different services 
and known protocol numbers to be used for TCP and UDP protocols. In such a 
25 case, a terminal which adds an identifier ID to a data packet but uses the 
common, known port number will always receive a service at least in a less 
suitable form even if the server did not support the version of the service that 
would suit the terminal best. This situation at the specific server only corre- 
sponds to the situation the terminal presently encounters in the prior art. This 
30 is preferable since the user is now able to view different sites on the Internet 
without all the time being compelled to know which service version he or she is 
to use. 

[0061] In the architecture of Figure 7, the terminal can in principle 
directly in the TCP header of the IP packet indicate the number of port Y' or X'. 
35 This should, however, also work parallel with the identifier number ID in order 
to achieve compatibility with the use of the known port numbers. Otherwise the 
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problem is that if the server does not support the use of the particular port, the 
terminal will receive no service at all. In such a case, the TCP program module 
converts e.g. the received port number Y into port number V if the identifier 
ID2 is aiso received in the same IP packet; otherwise the packet is supplied to 
5 port Y. 

[0062] In a similar manner, the TCP modules 1 and 2 and the UDP 
modules 1 and 2 could be indicated by a predetermined protocol number of 
their own in the architecture of Figure 5. This, when desired, should also work 
parallel with the embodiment of Figure 4 such that if the IP program module 
10 receives the current protocol number referring to the TCP or UDP protocol, 
and e.g. the identifier ID1, it still selects the protocol module TCP1, as de- 
) scribed in connection with Figure 5. If, on the other hand, a protocol number is 

received which directly points to the protocol module TCP1 , the TCP header 
and the application layer data are transmitted to this module. 
15 [0063] It would thus be preferable if the terminal could find servers 

providing a certain service in a desired format and possibly even the port 
numbers thereof without trying each server separately. A Service Location 
Protocol (SLP) standardized in connection with the Internet can preferably be 
used for this purpose. The SLP protocol is designed to make finding different 
20 network resources and services simpler. The SLP is a client-server-based 
service delivery process based on agent technology known per se, which en- 
ables the services desired by a user to be dynamically tied to the network ad- 
0 dress delivering the service. The structure of the SLP is described with refer- 

ence to Figure 3. A user issues a service request from application A in the 
25 user's terminal TE to a user agent UA in the network, the user agent being a 
program procedure which operates independently in the network for the user, 
searching through the network for a service according to the attributes defined 
by the user. The servers S1, S2 and S3 in the network present service infor- 
mation on the services they provide, such as address and configuring informa- 
30 tion on the services. Directory agents DA collect the service information pro- 
vided by the servers in a single place, which means that the directory agents 
DA are provided with information on all services available. 

[0064] When a user in a wireless network wishes to use a certain 
service, the user issues a service request from the application in his or her 
35 terminal TE to a user agent UA in the network for the service information on 
the particular service to be found. If the user agent UA knows the address of 
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the directory agent DA, the user agent UA can present a unicast service re- 
quest to the directory agent DA. If, again, the user agent U A does not know 
the address of the directory agent DA, the user agent UA can present mul- 
ticast service requests to a plurality of service-specifically defined servers. The 
5 servers S1, S2 and S3 register the service information on the services con- 
tained therein in the directory agent DA, which acknowledges the received 
information. The servers S1 to S3 are to register and update their service in- 
formation at determined intervals; otherwise the service information is re- ^ 
moved from the directories of the directory agent DA. The servers S1 to S3 

1 0 also inform the directory agent DA if the particular services are no longer used, 

in which case the directory agent DA removes the service information on the .> 
particular services from its directories. The directory agents DA are thus al- 
ways provided with updated information on the services available. In response 
to the unicast service request issued by the user agent UA, the directory agent 

15 DA examines whether a service according to the service request can be found 
in the directories and informs the user agent UA of the service information on 
a service it has possibly found, the user agent UA forwarding the address in- 
formation on the particular service to the terminal TE. On the basis of the ad- 
dress information, the terminal TE is able to configure to the desired service. 

20 Similarly, the servers S1 to S3 reply to the multicast service request issued by 
the user agent UA if the issued service request corresponds to the sen/ice in- 
formation on the services delivered by the server. The user agents are thus 
always provided with updated information on the address and configuration J 
information of the services available, and the terminal is able to connect to the 

25 service at a correct address. The SLP protocol is described in closer detail in 

RFC21 65 Internet request for change. 3 

[0065] The SLP protocol can also be preferably utilized in the dif- 
ferent embodiments of the present invention such that the network address, 
preferably the IP address, of the servers providing special services according 

30 to the invention is stored in connection with a directory agent DA according to 
the SLP protocol. In addition to the network address, available services and 
different formats thereof and port numbers, protocol numbers and/or identifiers 
to be used for requesting different services and different formats of a service 
are stored in connection with the directory agent. The particular server can 

35 update this information for the directory agent on a regular basis. Furthermore, 
the network comprises user agents and/or program procedures for creating 
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user agents UA for wireless terminals IT. Since the terminals IT move in differ- 
ent areas, it is not necessary to create permanent user agents for each termi- 
nal in a defined area but the terminals register in a user agent each time they 
enter a certain area defined by the directory agent DA. When the user device 
5 has been registered in the user agent UA, the user of the terminal can issue 
service requests to the directory agent DA through the user agent UA. 

[0066] When the user of the terminal is to set up a connection to a 
certain service, the terminal delivers a service request to its user agent UA in 
the network. The user of the terminal does not need to have any detailed in- 

10 formation on the particular service, such as at which network address the 
service is available or the telecommunication parameters used. In the issued 
service request, the user of the terminal can specify different attributes of the 
desired service, such as the service type, network protocols and service for- 
mats supported by the terminal, and certain information related to the applica- 

15 tion and/or features of the terminal that affects the selection of the service for- 
mat. If the terminal is a mobile one, the service request may also preferably 
specify the approximate location of the terminal on the basis of the position of 
its nodal point via which the terminal has been connected to the wired net- 
work. The user agent UA preferably presents the service request specified by 

20 the user of the terminal to the directory agent DA, which searches through the 
services registered in the directory agent DA by service agents SA for the 
service description specified by the particular service request. If a service ac- 
cording to the service request is available, the directory agent DA returns the 
service information on the particular service(s) to the user agent UA. Accord- 

25 ing to an embodiment of the invention, this also comprises port numbers 
and/or protocol numbers through which certain service formats are available. 
The user agent UA further delivers the information to the terminal TE, which is 
able to set up a connection to the network providing the service and the de- 
sired service by means of the received telecommunication parameters. If the 

30 terminal uses in the IP packet it transmits a certain protocol number or port 
number thus obtained, corresponding to the desired service format, the packet 
is automatically supplied to an application which provides the service in the 
desired form and which supports the features of the terminal. If the terminal 
only transmits a normal known protocol number and an identifier according to 

35 the invention, the packet will also end up in a correct application at the server. 
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[0067] The identifier information of the invention can also be used 
for routing an IP packet in the network. Depending on the identifier informa- 
tion, an IP packet having the same address can be routed in different ways in 
an embodiment of the invention; two or more servers (possibly virtuai) can be 
5 accessed in the service provider's own local area network using the same IP 
address. Figure 3 shows an example wherein two servers S3 and S3' provid- 
ing the same service, only suited for slightly different terminals, are connected 
to an LAN of the service provider. To the servers S3 and S3 1 , databases DB1 
and DB2 are also connected, comprising files in slightly different formats. 

10 Since the service should look uniform to the clients, the servers have the same 
IP address, at least outside the LAN. On the basis of the IP address, the IP 
packet arrives at a router R1 , which directs the packet to a correct server S3 or 
S3 1 by means of the identifier information ID in the packet. For example, if the 
IP packet comprises the ID1 or no identifier at all, the IP packet is routed to the 

1 5 server S3. If the packet comprises the identifier ID2, the packet is routed to the 
server S3 1 . This routing can be based e.g. on IP address conversion on the 
basis of the identifier ID. The identifier information ID can be utilized in the 
routing also elsewhere on the Internet Routing to a correct server within the 
network is determined according to the identifier information of the invention. 

20 [0068] The figures and the related description are only intended to 

illustrate the invention. The implementation of the invention may vary within 
the scope and spirit of the attached claims. 
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CLAIMS 

1. A method for implementing a service from a server (S1-3) to cli- 
ent devices (TE) having different features, the method comprising the steps of 

a client device (TE) transmitting an Internet Protocol (IP) packet 
5 comprising an IP header, a transfer protocol layer header and application layer 
data, 

routing the IP packet to the server (S1-3) according to a destination 
address of said IP header, 

transferring, at the server, the transport layer header and the appli- 
1 0 cation layer data from the I P layer to the transport layer protocol according to a 
protocol identifier of said IP header, 

transferring, at the server, the application layer data from the 
transfer protocol layer to the application layer according to a port number 
contained in said transfer protocol layer header, 
15 characterized in that 

* the client device (TE) includes, in the IP packet it transmits, infor- 
mation on a software interface (API) used by the applications of the client de- 
vice requesting the service, 

said information is used at the server (S1-3) for selecting and/or 
20 configuring either a file requested by the client device or an application inter- 
acting with the client device such that the service is provided in the form re- 
quired by the features of the particular client device (TE) which requested the 
service. 

2. A method as claimed in claim 1, characterized in that 

25 the server (S1-3) comprises a plurality of transport protocol layer 

units having the same protocol, each unit being connected to the application 
layer through a different application interface when each application interface 
supports the requested service in a different form, 

the application layer data is transferred at the server from the IP 

30 layer to one of said transport layer protocol units according to said protocol 
identifier of the IP header and said information. 

3. A method as claimed in claim 1, characterized in that 
the server (S1-3) comprises a plurality of ports in the transport pro- 
tocol layer, each port being connected to the application layer through a differ- 
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ent application interface when each application interface supports the re- 
quested service in a different form, 

the application layer data is transferred at the server from the trans- 
port protocol layer to the application layer through the port number contained 
5 in said transport protocol layer header and a port selected according to said 
information. 

4. A method as claimed in claim 1 , 2 or 3, c h a r a c t e r i z e d in 
that said information is located in the IP header of the IP packet, the transport 
layer header or the application data. 
10 5. A method as claimed in claim 1,2, 3 or 4, characterized 

in that 

the client device includes said information in the application layer 
data of the IP packet, 

the application layer is configured according to said information. 
15 6. A method as claimed in claim 5, characterized in that the 

application layer selects the type of the file to be transmitted to the client de- 
vice (TE) on the basis of said information. 

7. A method as claimed in any one of claims 1 to 6, charac- 
ter i z e d in that the client device (TE) retrieves the information about the 

20 servers (S1-3) providing the service in a desired form from a directory agent 
(DA). 

8. A terminal capable of requesting and receiving services from a 
server (S1-3) in a TCP/IP network, characterized in that the terminal 
(TE) includes, in an IP packet it transmits, information on an application re- 

25 questing a service and/or features of the client device so as to enable, at the 
server (S1-3), an application to be selected or configured by means of said 
information such that the service is provided in the form required by the fea- 
tures and /or application of the terminal (TE). 

9. A server in a TCP/IP network, which provides services to client 
30 devices (TE) having different features, the server (S1-3) comprising 

Internet Protocol (IP) means for receiving an IP packet transmitted 
by a client device (TE) and provided with an IP header, a transport protocol 
layer header and application layer data, 

at least one transport layer protocol unit to which the transport layer 
35 header and the application layer data are transferred from the IP means ac- 
cording to a protocol identifier of said IP header, 
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o 



at least one application to which the application layer data is trans- 
ferred from the transport layer protocol unit according to a port number con- 
tained in said transport protocol layer header, 
characterized in that 
5 the server (S1-3) is arranged to examine whether the client device 

(TE) has included, in the IP packet it transmits, information on an application 
requesting a service and/or features of the client device, 

the server (S1-3) is arranged to use said information for selecting or 
configuring the application such that the service is provided in the form re- 
10 quired by the features and/or application of the particular client device (TE) 
which requested the service. 
O 10. A server as claimed in claim 9, characterized in that 

the server (S1-3) comprises a plurality of transport protocol layer 
units having the same protocol, each unit being connected to the application 
15 layer through a different application interface when each application interface 
supports the requested sen/ice in a different form, 

said IP protocol means route the application layer data and the 
transport layer header to one of said transport layer protocol units according to 
a protocol identifier of said IP header and said information. 
20 1 1. A server as claimed in claim 9, characterized in that 

the server (S1-3) comprises a plurality of ports in the transport pro- 
tocol layer, each port being connected to the application layer through a differ- 
O ent application interface when each application interface supports the re- 

quested service in a different form, 
25 a protocol unit of the transport protocol layer is arranged to deliver 

q the application layer data to the application layer through the port number 

contained in said transport protocol layer header and a port selected according 
to said information. 

12. Aserveras claimed in claim 9, 10 or 11, characterized 
30 in that said information is located in the IP header of the IP packet, the trans- 
port layer header or the application data. 

13. A server as claimed in claim 9, 10, 11 or 12 character- 
ized in that said information is located in the application layer data of the IP 
packet, and that the application layer is configured or selects the format of the 

35 data to be transmitted according to said information. 
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14. A server as claimed in claim 12, characterized in that 
the application layer selects the type of the file to be transmitted to the client 
device (TE) on the basis of said information. 

15. A method for providing a service from a server (S1-3) to client 
5 devices, the method comprising the steps of 

the server (S1-3) broadcasting or multicasting an Internet Protocol 
(IP) packet comprising an IP header, a transfer protocol layer header and ap- 
plication layer data, 

routing the IP packet to the client devices, 
10 transferring, at the client device, the transport layer header and the 

application layer data from an IP layer to a transport layer protocol according 
to a protocol identifier of said IP header, 

transferring, at the server, the application layer data from the trans- 
port protocol layer to the application layer according to a port number con- 
1 5 tained in the transport protocol layer header, 

characterized in that 

the server (S1-3) includes, in the IP packet it transmits, information 
on a software interface below an application used for presenting the service, 
and that 

20 said information is used in the client device for configuring and/or 

downloading the application and application programming interface. 

16. A method as claimed in claim 15, characterized in that 
the client device downloads, on the basis of said information, nec- 
essary program modules suitable for the software interface of the client device 

25 from servers on the Internet in order to present the service content itself. 

17. A server (S1-3) in a TCP/IP network, which provides services to 
client devices having different features, the server comprising means for 
transmitting IP packets in the broadcast or multicast form to the client devices, 
characterized in that the server (S1 -3) is arranged to include, in an IP 

30 packet it transmits, information on a software interface below an application 
used for presenting a service so as to enable a client device to use said infor- 
mation for configuring and/or downloading the application and application pro- 
gramming interface. 

18. A server (S1-3) in a broadcast network, which provides services 
35 to client devices having different features, the server comprising means for 

transmitting IP packets in broadcast frames to the client devices, c h a r a c - 
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te rize d in that the server (S1-3) is arranged to include, in identifier infor- 
mation of a broadcast frame IP packet, information on a software interface 
below an application used for presenting a service so as to enable a client de- 
vice to use said information for configuring and/or downloading the application 
5 and application programming interface or a protocol program. 

19. A terminal capable of requesting and receiving services from a 
server (S1-3) in a TCP/IP network, characterized in that the terminal 
configures and/or downloads an application and an application programming 
interface on the basis of information located in an Internet Protocol (IP) packet 

10 received from the server (S1-3), said information relating to a software inter- 
face below the application used for presenting a service. 

20. A terminal capable of requesting and receiving services from a 
broadcast network, characterized in that the terminal configures 
and/or downloads an application and an application programming interface or 

15 a protocol program on the basis of information located in identifier information 
on a broadcast frame received from the broadcast network, said information 
relating to a software interface below the application used for presenting a 
service. 

21 . A method for implementing a service from a server (S1-3) to cli- 
20 ent devices having different features, the method comprising the steps of 

a client device (TE) transmitting an Internet Protocol (IP) packet 
comprising an IP header, a transfer protocol layer header and application layer 
data, 

routing the IP packet to the server (S1-3) according to a destination 
25 address of said IP header, 

characterized in that 

the client device (TE) includes, in the IP packet it transmits, infor- 
mation on the application requesting the service and/or features of the client 
device, 

30 said information, together with the IP address, is used for routing 

the IP packet to a server (S1-3) which provides a service in the form required 
by the features and/or application of the particular client device (TE) which re- 
quested the service. 

22. A method as claimed in claim 21 .characterized in that 
35 two or more servers providing different forms of a single service have the 

same IP address. 
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23. A router routing Internet Protocol (IP) packets, charac- 
terized in that in the routing, the router uses not only an IP destination ad- 
dress but also identifier information, which has been included in an IP packet 
by a client device which transmitted the IP packet, said information relating to 
an application requesting the service and/or features of said client device. 
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